Chapitre 13 [dev] - Créer des tickets et gérer la communication et l’avancement avec un Kanban

La gestion de projet s’effectue grâce à un Kanban sur GitLab. Le Kanban est mis en place par les [ChfDev] lors de l’étape “Mettre en place un projet de développement avec RStudio et GitLab”. Chaque [dev] se réfère à tout moment au contenu du Kanban pour savoir quelles fonctionnalités / bugs sont à prendre en charge en priorité. Chaque [dev] indique l’avancée de son travail dans le Kanban et dans les tickets associés. Les discussions avec les membres du comité éditorial [Red/Rel] se passe dans les tickets pour assurer le référencement de chaque décision à l’endroit approprié.

13.1 Présentation du Kanban et des labels

Le Kanban est nommé Board sur GitLab. Vous le trouvez dans la colonne de gauche, sous le menu Issues > Boards (ou Tickets > Tableaux de bord). Les tickets et donc le Kanban peuvent avoir les labels suivants :

Bloqué (gris) : En attente d’infos complémentaires par les éditos [Ed]
En attente (vert pâle) {pas de colonne} : Issue non bloquante, en attente d’être prête, mais, n’étant pas une priorité pour le moment
Prêt (vert vif) : Le cahier des charges est clair, on sait ce qu’il faut faire, on est prêt à la prendre en charge
En cours (bleu) : Quelqu’un traite l’issue
Révision (orange) : L’issue est en merge request vers dev
A valider (violet) : Attente validation par les éditos [Ed] pour passage en production
Labels supplémentaires si besoin (bug, feature, priorité 1, …)

En version complète, le Kanban ressemble au tableau de bord suivant :

Vous pouvez observer des tickets/issues répartis dans les différentes colonnes. Selon l’avancement de la prise en charge des tickets, ils sont déplacés de la gauche vers la droite par les [ChfDev] ou les développeurs.

13.2 Transformer la liste des demandes du comité éditorial en tickets

Dans la phase “Comment définir ses besoins et le contenu”, le comité éditorial doit avoir fourni la liste de ses besoins pour la publication. Les fonctionnalités prioritaires doivent aussi être définies lors de cette phase. Les [ChfDev] divisent les fonctionnalités en tickets. Il s’agit de découper les demandes d’un point de vue technique, en sous-tâches de développement. Il n’est pas toujours évident de trouver le découpage adéquat entre diviser en tâches d’une heure ou en tâches de 15 jours.

Si vous ne savez pas par où commencer, créez des (méta-issues) pour chaque chapitre. Au minimum on s’assure que toutes les parties demandées sont bien référencées comme issue. Vous pourrez ensuite y référencer les sous-issues qui en découlent.

Nous recommandons donc un découpage selon la structure de la production (par page, chapitre, section, onglet, …). De cette manière, on pourra recoller les morceaux plus facilement lorsqu’ils auront été développés. Ce sera plus pratique pour le comité éditorial de suivre le fil des développements s’ils peuvent se raccrocher au découpage qu’ils ont mis tant de temps à définir. Et ce sera plus intéressant pour les développeurs de partir sur des petites fonctionnalités dont le résultat est visible directement dans la composition finale. Penser au maximum à la répartition de tâches qui peuvent se réaliser en parallèle de manière la plus indépendante possible. Il s’agira ensuite de réfléchir aux fonctions qui seront équivalentes sur différentes parties pour noter les liens dans les différents tickets créés et éventuellement définir l’ordre d’exécution.

Si vous avez suivi le conseil de noter le cahier des charges dans le Wiki, n’hésitez pas à y lister les liens vers les tickets créés. Ainsi, vous saurez ce que vous avez déjà pris en compte et le comité éditorial [Ed] pourra aussi plus facilement s’en assurer. Par ailleurs, s’il s’avère que le comité éditorial [Ed] décide de modifier des demandes en cours en route, ils sauront qu’ils ne peuvent pas le faire sans discussion préalable lorsqu’un ticket est déjà ouvert.

Dans le cadre d’un développement PROPRE, en suivant les recommandations de développement en mode “Rmd first”, pour l’écriture d’un chapitre vous aurez toujours à créer des vignettes pour chaque morceau de code. Dans un premier temps, chaque développeur créera un morceau dans une vignette séparée, quitte à tout recoller à la fin.

À quoi faut-il penser lors du découpage ?

Indépendance de la résolution des tickets
Étape de préparation des données. Probablement bloquant pour beaucoup de tickets suivant.
- Cela inclut la création de petits jeux de données reproductibles qui seront utilisés lors du développement, des exemples de chaque fonction développées et de leurs tests. Ces mini-jeux de données resteront dans le package pour les tests et la documentation en intégration continue. Vous devrez donc définir en amont ce qui est diffusable ou non parmi vos données.
Chaque partie contient potentiellement :
- une extraction de données
- un calcul d’indicateurs
- l’affichage d’un tableau
- l’affichage d’un graphique
- l’affichage d’un phrase “in-line” pour présenter en toutes lettres le résultat de calculs.
Toutes ces étapes et fonctions peuvent être paramétrables selon la zone géographique ou la période sur laquelle on travaille.
Séparer au maximum le fond de la forme. Par exemple, pour un graphique, faîtes d’abord valider l’information présentée et le type de graphique, avant de faire valider sa version avec le thème / l’apparence définitive. De même pour les tableaux.

13.3 Prioriser et assigner les tickets

Par défaut tous les tickets sont listés sur le Kanban principal dans la première colonne (open). Vous pouvez d’ores et déjà trier les tickets bloqués, ceux qui nécessitent des précisions supplémentaires par le comité éditorial. Il s’agit des tickets qu’on ne peut pas résoudre sans information complémentaire. Les tickets qui nécessitent la résolution d’un autre ticket au préalable ne sont pas à lister ici, mais l’information est consignée dans sa description. Choisissez ensuite une dizaine de tickets à réaliser en priorité et les glisser vers la colonne Prêt. Il ne faut pas en mettre de trop. Vous pouvez pré-trier les tickets qui arriveront après ceux qui sont prêts, en leur assignant l’étiquette En attente. Cela signifie que ce qu’il faut faire est clair pour les [ChfDev] et que le ticket attend son tour pour passer en Prêt. Notez que vous pouvez ré-ordonner les tickets dans chaque colonne, en mettant en haut de colonne les tickets avec une priorité plus élevée.

Il est conseillé de ne pas avoir plus d’une dizaine de tickets dans les colonnes Prêt, En cours et Révision.

Définissez ensuite, en discussion avec les développeurs, qui est assigné à quel ticket. Les [ChfDev] listent sur le logiciel de Chat les tickets à prendre et peuvent éventuellement proposer des tickets directement à certains développeurs nommés.

Notez que vous pouvez définir des milestones ou points d’étapes dans le menu Issues > Milestones. Ce sont des objectifs que vous fixez dans le temps, avec une date de livraison. Par exemple, la livraison du premier chapitre de la publication reproductible. Chaque ticket peut être assigné à un milestone. Cela vous permet d’organiser votre Kanban mais aussi de suivre l’avancement spécifique du Milesones dans sa page de suivi.

13.4 Utilisation du Kanban pour le suivi de projet

Le Kanban c’est le seul endroit où on peut savoir où on en est. En tout temps.

Les développeurs [Dev] et [ChfDev] le font vivre au fur et à mesure du développement. Le moment précis du mouvement d’une colonne à une autre apparaît dans la documentation côté développeurs : “Développer en collaboration sur un projet git avec GitLab et RStudio”. On peut toutefois résumer l’utilisation du Kanban ainsi :

Bloqué : Les développeurs y déplacent les tickets qui nécessitent des informations complémentaires de l’équipe éditoriale [Ed] pour être traités. On y trouve donc tout ce qui ne peut pas être réglé entre [Dev].
En cours : Les développeurs l’utilisent pour indiquer la prise en charge d’une fonctionnalité. Les développeurs qui prennent un ticket le déplace de la colonne Prêt vers cette colonne En cours.
Révision : Les développeurs qui ont résolu un ticket ouvrent une Merge Request (MR) pour fusion de leur branche vers la branche principale de développement : dev. Les [ChfDev] révisent la Merge Request et décident ou non de l’accepter.
A valider : Lorsque la MR est acceptée, la balle est renvoyée dans le camp des éditos [Ed]. Les [ChfDev] glissent le ticket dans cette colonne. Ils indiquent clairement aux [Ed] comment valider le contenu du ticket, où trouver les sites web, les lignes de commandes, … pour valider dans de bonnes conditions.
Closed : Une fois le ticket validé, les commit peuvent être intégrés à la branche stable : production. Le ticket est fermé.

Le comité éditorial [Ed] viendra régulièrement voir ce qu’il se passe dans le Kanban. Ils vérifieront en particulier que tout est pris en charge dans la partie Bloqué et en cours de résolution. Ils regarderont attentivement les tickets de la colonne A valider pour voir s’il n’y a pas des tickets qui peuvent être validés en asynchrone plutôt que d’attendre la prochaine réunion.

13.5 Utilisation du Kanban pour la communication

Lorsque les développeurs prennent en charge un ticket, il est déplacé dans la colonne En cours. L’ensemble des discussions relevant de ce ticket doit être consigné en tant que commentaire dans ce ticket. Si des discussions se sont déroulées ailleurs (Chat, réunions, …), la partie du compte-rendu en lien avec un ticket doit être copié dans un commentaire du ticket en question.

Si vous souhaitez un retour d’une personne en particulier, notez que vous pouvez nommer n’importe quel utilisateur (ayant accès au dépôt) dans le commentaire d’un ticket. De cette manière, vous pouvez interagir en asynchrone sur le développement de fonctionnalités. La personne nommée reçoit un email avec le contenu du commentaire et uniquement le contenu de ce commentaire. Ainsi, si vous nommez quelqu’un dans un ticket pour susciter une réaction, posez une question claire dans ce commentaire et qui ne nécessite pas de relire la totalité des messages du ticket pour comprendre ce dont il s’agit. En particulier, lors de l’étape de validation d’un ticket. Veillez aussi à rester parcimonieux dans cette pratique pour ne pas encombrer les boîtes mails plus que de raison. Notamment parce que la totalité des commentaires qui seront ensuite ajoutés à ce ticket sera envoyée à toutes les personnes nommées. Par ailleurs, vous pouvez faire une annonce / demande de volontaires sur le logiciel de Chat au préalable si vous ne savez pas précisément à qui poser votre question.

Privilégier les interactions en asynchrone. Cela permet à chacun de définir son emploi du temps et de répondre quand il peut. Vous trouverez toujours autre chose à faire d’aussi intéressant en attendant une réponse. De la documentation par exemple !